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(54) Method and apparatus for managing multiprocessor graphical workload distribution 

(57) An apparatus for utilizing multiple processors to 
render graphical objects for display including apparatus 
for storing in memory a list of pixel locations assigned to 
each of the processors, apparatus for scan converting 
each received graphical object into pixels, and each 
processor including apparatus for rendering graphical 
object pixels at pixel locations assigned to the processor. 
In addition, a method of utilizing multiple processors to 
render graphical objects for display including the steps 
of storing in memory a list of pixel locations assigned to 
each of the processors, scan converting each received 
graphical object into pixels, and each processor render- 
ing graphical object pixels at pixel locations assigned to 
the processor. 
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Description 

The present invention relates to a method and ap- 
paratus for managing a graphical workload across mul- 
tiple processors. 

In computer graphics systems, it is desirable to 
render multiple objects into a frame buffer for display as 
quickly as possible. However, the rendering process has 
become more complex and computationally intensive as 
users demand more detailed results using more objects 
rendered more quickly, including providing realtime mo- 
tion, while using more computationally intensive 
processing techniques such as color, texture, lighting, 
transparency and other rendering techniques. As a re- 
sult, multiprocessing has been utilized to handle this ever 
increasing graphical workload. 

Many techniques for utilizing multiple processors 
are described in pages 855 to 922 of "Computer Graph- 
ics Principles and Practice", second edition, 1990, by Fo- 
ley, Van Dam, Feiner, and Hughes. For example, each 
object to be rendered may be assigned to a specific proc- 
essor for processing including the use of a processor for 
each object in very high performance systems. 

In accordance with the present invention, there is 
now provided apparatus for utilizing multiple processors 
to render graphical objects for display comprising: 
means for storing in memory a list of pixel locations as- 
signed to each of said processors; means for scan con- 
verting each received graphical object into pixels; and 
each processor including means for rendering graphical 
object pixels at pixel locations assigned to said proces- 
sor 

Viewing the present invention from another aspect, 
there is now provided a method for utilizing multiple proc- 
essors to render graphical objects for display comprising 
the steps of: storing in memory a list of pixel locations 
assigned to each of said processors; scan converting 
each received graphical object into pixels; and each 
processor rendering graphical object pixels at pixel loca- 
tions assigned to said processor. 

Viewing the present invention from yet another as- 
pect, there is now provided a data processing system 
comprising: a memory for storing data to be processed; 
a processing means for processing data stored in mem- 
ory; and a graphics processing system utilizing multiple 
processors to render graphical objects received from 
said processing means comprising: means for storing in 
memory a list of pixel locations assigned to each of said 
processors; means for scan converting each received 
graphical object into pixels; and each processor includ- 
ing means for rendering graphical object pixels at pixel 
locations assigned to said processor. 

In a preferred embodiment of the present invention 
there is provided an apparatus for utilizing multiple proc- 
essors to render graphical objects for display including 
apparatus for storing in memory a list of pixel locations 
assigned to each of the processors, apparatus for scan 
converting each received graphical object into pixels, 



and each processor including apparatus for rendering 
graphical object pixels at pixel locations assigned to the 
processor. 

In another preferred embodiment of the present in- 
5 vention, there is provided a method of utilizing multiple 
processors to render graphical objects for display includ- 
ing the steps of storing in memory a list of pixel locations 
assigned to each of the processors, scan converting 
each received graphical object into pixels, and each 
10 processor rendering graphical object pixels at pixel loca- 
tions assigned to the processor. 

Preferred embodiments of the present invention will 
now be described with reference to the accompanying 
drawings in which: 

15 

Figure 1 is a diagram of a typical digital computer 
utilized by a preferred embodiment of the invention; 

Figure 2 is a block diagram illustrating the layers of 
20 code typically utilized by the host computer and 
graphics adapter to perform graphics functions; 

Figures 3A-3C show various ways a graphical work- 
load can be distributed by pixel location according 
25 to a preferred embodiment of the invention; 

Figure 4 is a block diagram illustrating data struc- 
tures that may be used in the graphics adapter mem- 
ory in the preferred embodiment of the invention; 

30 

Figure 5 is a flowchart illustrating a preferred method 
for generating a pixel ownership buffer or a region 
ownership list; and 

35 Figure 6 is a flowchart illustrating a preferred method 
for each processor to handle the graphical workload 
while determining ownership of pixels or regions. 

This disclosure describes an improved method and 
40 apparatus for managing a graphical workload such as 
rendering across multiple processors by pixel location or 
by display region. That is, a processor may process ren- 
dering of pixels for particular regions of a display or win- 
dow based on various allocation techniques. These al- 
45 location techniques may be dynamic such that a partic- 
ular pixel or display region may be processed by a first 
processor for a period of time and then rendered by a 
second processor for another period of time. This allows 
for great flexibility in managing the graphical workload 
so across multiple processors. 

Figure 1 is a block diagram of a typical digital com- 
puter 100 utilized by a preferred embodiment of the in- 
vention. The computer includes main processor(s) 110 
coupled to a memory 120 and a hard disk 125 in com- 
55 puter box 1 05 with input device(s) 1 30 and output device 
(s) 140 attached. Main processor(s) 110 may include a 
single processor or multiple processors. Input device(s) 
130 may include a keyboard, mouse, tablet or other 
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types of input devices. Output device(s) 1 40 may include 
a text monitor, plotter or other types of output devices. 
Computer readable removable media 190, such as a 
magnetic diskette or a compact disc, may be inserted 
into an input/output device 1 80, such as a disk drive or 
a CD-ROM (compact disc - read only memory) drive. 
Data is read from or written to the removable media by 
the I/O device under the control of the I/O device con- 
troller 170. The I/O device controller communicates with 
the main processor through across bus 160. Main mem- 
ory 120, hard disk 125 and removable media 1 90 are all 
referred to as memory for storing data for processing by 
main processor(s) 110. 

The main processor may also be coupled to graph- 
ics output device(s) 150 such as a graphics display 
through a graphics adapter 200. Graphics adapter 200 
receives instructions regarding graphics from main proc- 
essors) 1 10 on bus 160. The graphics adapter then ex- 
ecutes those instructions with graphics adapter proces- 
sors 220 coupled to a graphics adapter memory 230. The 
graphics processors in the graphics adapter then exe- 
cute those instructions and updates frame buffer(s) 240 
based on those instructions. Graphics processors 220 
may be a pipeline of processors in series, a set of parallel 
processors, or some combination thereof, where each 
processor may handle a portion of a task to be complet- 
ed. Graphic processors 220 may also include special- 
ized rendering hardware for rendering specific types of 
primitives. Graphics memory 230 is used by the graphics 
processors to store information being processed, such 
as received object data, intermediate calculated data 
(such as a stencil buffer or partially rendered object da- 
ta), and completed data being loaded into the frame buff- 
er 240. Frame buffer(s) 240 includes data for every pixel 
to be displayed on the graphics output device. A RAM- 
DAC (random access memory digital-to-analog convert- 
er) 250 converts the digital data stored in the frame buff- 
ers into RGB signals to be provided to the graphics dis- 
play 150 thereby rendering the desired graphics output 
from the main processor. 

Figure 2 is a block diagram illustrating the layers of 
code typically utilized by the host computer and graphics 
adapter to perform graphics functions. An operating sys- 
tem 300 such as UNIX provides the primary control of 
the host computer. Coupled to the operating system is 
an operating system kernel 31 0 which provides the hard- 
ware intensive tasks for the operating system. The op- 
erating system kernel communicates directly with the 
host computer microcode 320. The host computer mi- 
crocode is the primary instruction set executed by the 
host computer processor. Coupled to the operating sys- 
tem 300 are graphics applications 330 and 332. This 
graphics application software can include software pack- 
ages such as Silicon Graphic's GL, IBM's graPHIGS, 
MIT's PEX, etc. This software provides the primary func- 
tions of two dimensional or three dimensional graphics. 
G raphics applications 330 and 332 are coupled to graph- 
ics application API (application program interface) 340 



and 342, respectively. The API provides many of the 
computationally intensive tasks for the graphics applica- 
tion and provides an interface between the application 
software and software closer to the graphics hardware 

5 such as a device driver for the graphics adapter. For ex- 
ample, API 340 and 342 may communicate with a GAI 
(graphics application interface) 350 and 352, respective- 
ly. The GAI provides an interface between the application 
API and a graphics adapter device driver 370. In some 

10 graphics systems, the API also performs the function of 
the GAI. 

The graphics application, API, and GAI are consid- 
ered by the operating system and the device driver to be 
a single process. That is, graphics applications 330 and 

15 332, API 340 and 342, and GAI 350 and 352 are consid- 
ered by operating system 300 and device driver 370 to 
be processes 360 and 362, respectively. The processes 
are identified by the operating system and the device 
driver by a process identifier (PI D) that is assigned to the 

20 process by the operating system kernel. Processes 360 
and 362 may use the same code that is being executed 
twice simultaneously, such as two executions of a pro- 
gram in two separate windows. The PID is used to dis- 
tinguish the separate executions of the same code. 

25 The device driver is a graphics kernel which is an 
extension of the operating system kernel 310. The 
graphics kernel communicates directly with microcode 
of the graphics adapter 380. In many graphics systems, 
the GAI, or the API if no GAI layer is used, may request 

30 direct access from the GAI or API to the adapter microc- 
ode by sending an initial request instruction to the device 
driver. In addition, many graphics systems also allow the 
adapter microcode to request direct access from the 
adapter microcode to the GAI or API if no GAI is used by 

35 sending an initial request instruction to the device driver. 
Both processes will hereinafter be referred to as direct 
memory access (DMA). DMA is typically used when 
transferring large blocks of data. DMA provides for a 
quicker transmission of data between the host computer 

40 and the adapter by eliminating the need to go through 
the display driver other than the initial request for the de- 
vice driver to set up the DMA. In some cases, the adapter 
microcode utilizes context switching which allows the 
adapter microcode to replace the current attributes being 

45 utilized by the adapter microcode. Context switching is 
used when the adapter microcode is to receive an in- 
struction from a graphics application that utilizes different 
attributes than the adapted microcode is currently using. 
The context switch is typically initiated by the device drrv- 

50 er which recognizes the attribute changes. 

Blocks 300-340 are software code layers that are 
typically independent of the type of graphics adapter be- 
ing utilized. Blocks 350-380 are software code layers that 
are typically dependent upon the type of graphics adapt- 

55 er being utilized. For example, if a different graphics 
adapter were to be used by the graphics application soft- 
ware, then a new GAI, graphics kernel and adapter mi- 
crocode would be needed. Iff addition, blocks 300-370 
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typically reside on and are executed by the host compu- 
ter. However, the adapter microcode 380 typically re- 
sides on and is executed by the graphics adapter. How- 
ever, in some cases, the adapter microcode is loaded 
into the graphics adapter by the host computer during s 
initialization of the graphics adapter. 

In typical graphics systems, the user instructs the 
graphics application to construct an image from a two or 
three dimensional model. The user first selects the loca- 
tion and type of light sources. The user then instructs the 1 o 
application software to build the desired model from a 
set of predefined or user defined objects. Each object 
may include one or more coplanar drawing primitives de- 
scribing the object. For example, a set of drawing prim- 
itives such as many triangles may be used to define the is 
surface of an object. The user then provides a perspec- 
tive in a window to view the model, thereby defining the 
desired image. The application software then starts the 
rendering of the image from the model by sending the 
drawing primitives describing the objects to the adapter 20 
microcode through the API, the GAI, and then the device 
driver unless DMA is used. The adapter microcode then 
renders the image on the graphics display by clipping 
(i.e. not using) those drawing primitives not visible in the 
window and the adapter microcode breaks each remain- 2s 
tng drawing primitive into visible pixels from the perspec- 
tive given by the user The pixels are then loaded into 
the frame buffer, often with the use of a depth buffer in 
the case of a three dimensional model. This step is very 
computationally intensive due to the number of drawing 30 
primitives, variables, and pixels involved. The resulting 
image stored in the frame buffer and displayed on the 
graphics display typically does not carry the original in- 
formation such as which drawing primitive or object the 
pixel was derived from. As a result, the image may need 35 
to be rerendered in part or in whole if the window, the 
user perspective, the model, the lighting, etc. are modi- 
fied. 

The techniques of the present invention could be uti- 
lized in many locations such as the adapter microcode 40 
which is close to the adapter frame buffer. This approach 
would also be relatively quick and fairly easy to imple- 
ment. In addition, the present invention could be applied 
in the graphics application software wherein the ren- 
dered image is also stored in system memory either prior *s 
to the image being rendered or subsequently by the 
graphics adapter passing the data back up to the graph- 
ics application software. This approach would probably 
be slower but would allow for utilization of this technique 
on preexisting graphics adapters. The present invention so 
could also be implemented in hardware in the graphics 
adapter processor. This approach is extremely quick but 
may necessitate specialized hardware. As would be ob- 
vious to one of ordinary skill in the art, the present inven- 
tion could be applied in many other locations within the ss 
host computer or graphics adapter. 

Figures 3A-3C show various ways a graphical work- 
load can be distributed by pixel location according to a 
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preferred embodiment of the invention. Each figure 
shows a window or display where certain regions are al- 
located to various processors for rendering pixels in 
those regions. 

Figure 3A shows a round robin approach for distrib- 
uting the graphical workload. A display or window 400 
may be divided into multiple regions of pixels that are 
distributed across multiple processors in a round robin 
fashion. In the present example there are sixteen regions 
and three processors P0, P1 and P2. 

Figu re 3B shows a stripe allocation approach for dis- 
tributing the graphical workload by region of pixels. A dis- 
play or window 400 may be divided into multiple stripes 
where each processor is assigned one stripe. In the 
present example there are six stripes and six processors 
P0, P1, P2, P3, P4and P5. 

Figure 3C shows a mixed allocation procedure 
where the processors may be assigned regions of pixels 
using various techniques. In the present example there 
are many regions allocated to three processors P0 t P1 
and P2. The mixed allocation approach allows the allo- 
cation to be optimized based on various parameters. For 
example, the breakdown and allocation of pixels or re- 
gions of pixels may be based on the number of objects 
in a particular areas of the display. The breakdown and 
allocation may also be based on the amount of workload 
each processor already has. The breakdown and alloca- 
tion of pixels or regions of pixels may also be dynamic 
whereby the pixels may be reassigned to different proc- 
essors over time based on various factors. In any ap- 
proach, the present invention allows for great flexibility 
in distributing the workload. 

Figure 4 is a block diagram illustrating data struc- 
tures that may be used in the graphics adapter memory 
230 in the preferred embodiment of the invention. 

A pixel ownership buffer 231 is used to store identi- 
fiers (IDs) of the processor that owns each pixel. That is, 
there is one entry corresponding to every pixel in the 
frame buffer, and that entry contains an identifier of the 
processor that handles processing for that pixel including 
rendering. These entries may be modified over time to 
dynamically manage the processor workload. 

A region ownership list 236 may be used as an al- 
ternative to the pixel ownership buffer 231 described 
above. In this alternative, the region ownership list in- 
cludes one entry for each region and may be fixed or 
variable length, variable length would allow for greater 
flexibility in allocating regions but may be difficult to man- 
age. Each entry includes five elements that describe the 
minimum X value (X1), the maximum X value (X2), the 
minimum Y value (Y1 ), the maximum Y value (X2), and 
the identifier of the processor that owns the region. As a 
result, the size and location of the region is defined and 
ownership is established of the region. In another alter- 
native embodiment, the size and location of the regions 
may be fixed such that only the identifier of the processor 
that owns the region may be displayed. 

Figure 5 is a flowchart illustrating a preferred method 
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for generating a pixel ownership buffer or a region own- 
ership list. This process may be executed at any time to 
establish processor ownership of regions or pixels. In ad- 
dition, this process may be repeatedly executed to con- 
stantly optimize the allocation of the graphical workload. 

In a first step 500, it is determined whether block al- 
location of the pixels may be performed. This type of al- 
location has the advantage of being simple and quick. If 
yes, then in step 505, the processor ownership is allo- 
cated in a round- rob in fashion in uniform blocks of pixels 
or regions according to the preferred embodiment as 
shown in Figure 3A. During this process, the data struc- 
tures shown in Figure 4 or their equivalents may be gen- 
erated which indicate which processors own which pixels 
or regions. However, in alternative embodiments, the re- 
gions need not be uniform and may be allocated in some 
other manner other than round-robin. Upon completion 
of step 505, processing ends for this process until it is 
reexecuted. If no in step 500 above, then processing 
continues to step 510. 

In step 51 0, it is determined whether stripe allocation 
of the pixels may be performed. This type of allocation 
also has the advantage of being simple and quick. If yes, 
then in step 515, the processor ownership is allocated in 
a round-robin fashion in uniform stripes of pixels or re- 
gions according to the preferred embodiment as shown 
in Figure 3B. During this process, the data structures 
shown in Figure 4 or their equivalents may be generated 
which indicate which processors own which pixels or re- 
gions. However, in alternative embodiments, the regions 
need not be uniform and may be allocated in some other 
manner other than round-robin. Upon completion of step 
51 5, processing ends for this process until it is reexecut- 
ed. If no in step 510 above, then processing continues 
to step 520. 

In step 520, it is determined whether the user (or an 
application program) may wish to allocate the pixels or 
regions. This type of allocation has the advantage of al- 
lowing the user or application programs to generate op- 
timized ownership patterns that anticipate upcoming 
graphical workloads. If yes, then in step 525, a buffer or 
list is obtained from the user or application program for 
storage in the graphics adapter memory. Upon comple- 
tion of step 525, processing ends for this process until it 
is reexecuted. If no in step 520 above, then processing 
continues to step 530. 

In step 530, it is determined whether a mixed allo- 
cation of the pixels may be performed. This type of allo- 
cation has the advantage of being extremely flexible for 
optimizing allocation of pixel ownership. If no in step 530, 
then processing ends for this process until it is reexecut- 
ed. However, since no allocation has occurred, then a 
default or previous allocation continues to control which 
processors own which pixels or regions. If yes in step 
530, then processing continues to step 535. 

In step 535, an object to be processed is retrieved. 
In step 540, the object may be split into subobjects and 
a first one of the subobjects is extracted by generating 



or retrieving its vertices. This splitting process is partic- 
ularly useful for handling three dimensional objects 
which have many faces, each face a subobject. In step 
545, the window coordinates of the subobject are com- 
s puted for processing. In step 550, a bounding box con- 
taining the subobject is calculated and stored. A bound- 
ing box is a region that contains the subobject and may 
have the maximum and minimum values for X, Y and Z 
coordinates in its boundary. The bounding box is prefer- 
10 ably stored with other parameters that describe the ob- 
ject. In step 555, it is determined whether the last sub- 
object for the given object has been processed. If not, 
then processing returns to step 540 for processing the 
next subobject. If yes, then processing continues to step 
'5 560 where it is determined whether the last object has 
been processed. If not, then processing returns to step 
535 for processing the next object. If yes, then process- 
ing continues to step 565. 

in step 565, the pixel ownership buffer or the region 
ownership list may be generated from all the previously 
calculated bounding boxes. In the preferred embodi- 
ment, the K-D tree method may be used to allocate the 
pixels or regions based on the distribution of the object 
bounding boxes in the display or window. The K-D meth- 
od is a well known technique for allocating limited re- 
sources and is described in Algorithm in Combinatorial 
Geometry , H. Edelsbrunner, Springer- Verlag publisher, 
1 987. Of course, other optimization techniques may be 
utilized. 

The above described steps 500, 510, 520 and 530 
may be dynamically controlled. That is, they may be con- 
trolled by the user or an application program. In addition, 
they may be controlled by an optimization process that 
determines which is the optimum approach to use for a 
given situation. 

Figure 6 is a flowchart illustrating a preferred method 
for each processor to handle the graphical workload 
while determining ownership of pixels or regions. This 
process may be executed concurrently and in parallel by 
all the processors. 

In a first step 600, an object is retrieved for process- 
ing. The object retrieval may include comparing the 
bounding box for the object (previously determined and 
stored with the object in step 550 described above) to 
the regions that the processor owns if a region ownership 
list is utilized. Of course, other typical clipping techniques 
may be utilized. 

Once retrieved, in step 605, the object may be split 
into subobjects as described above with reference to 
540. Of course, other splitting techniques may be utilized 
in this step based on the type of graphical activities the 
processor is handling. 

Once the subobject is extracted, then in step 610, 
various variables may be calculated for use in calculating 
colors, shading, textures, lighting, transparency, dither- 
ing, and other possible variables. The type of variables 
calculated may change depending on the types of graph- 
ical activities being performed by the processor. 
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In step 615, the subobject is then scan converted 
into pixels. In step 620, each pixel is checked to see if it 
is owned by the processor by comparing the identifier of 
the processor with the identifier stored in the pixel own- 
ership buffer or the region ownership list for that pixel. 

If yes in step 620, indicating that the processor owns 
this pixel, then the processor processes the pixel. This 
processing may include using the variables from step 
610 and other known variables to calculate the color, 
lighting, transparency, etc. of that pixel. The calculated 
pixel values are then stored in the frame buffer for dis- 
play. This process is typically known as rendering. Clear- 
ly, if a processor does not own a pixel, many computa- 
tionally intensive calculations are avoided, thereby 
speeding up the rendering process. 

If no in step 620 or if step 625 has been completed, 
then processing continues to step 630. In step 630, it is 
determined whether the last pixel for the subobject has 
been rendered. If no, then processing returns to step 615 
for generating the next pixel for processing. If yes in step 
630, then processing continues to step 635. In step 635, 
it is determined whether the last subobject for the object 
has been processed. If no, then processing returns to 
step 605 for generating the next subobject. If yes in step 
635, then processing continues to step 640. In step 640, 
it is determined whether the last object has been proc- 
essed. If no, then processing returns to step 600 for re- 
trieving the next object. If yes in step 640, then process- 
ing ends for the processor until further objects are avail- 
able for processing. It is at this time that the processor 
may reexecute the allocation process described in Fig- 
ure 5 above to reallocate some workload to the now idle 
processor. 

The present invention has many advantages over 
the prior art. The present invention is very flexible and 
dynamic and allows optimization techniques to be used 
to optimize operation of the rendering. These optimiza- 
tion techniques may be applied in a predetermined fash- 
ion or they may be dynamically applied during runtime. 
The present invention may be optimized based on the 
current or planned workload of each processor, the 
number of processors, the number and location of ob- 
jects on a display, as well as other measures of optimi- 
zation. 

Although the present invention has been fully de- 
scribed above with reference to specific embodiments, 
other alternative embodiments will be apparent to those 
of ordinary skill in the art. Therefore, the above descrip- 
tion should not be taken as limiting the scope of the 
present invention which is defined by the appended 
claims. 



Claims 

1 . Apparatus for utilizing multiple processors to render 
graphical objects for display comprising: 

means for storing in memory a list of pixel loca- 



tions assigned to each of said processors; 

means for scan converting each received 
graphical object into pixels; and 

each processor including means for rendering 
s graphical object pixels at pixel locations assigned to 
said processor. 

2. Apparatus as claimed in Claim 1 wherein said 
means for storing includes means for dynamically 

10 determining which pixel locations are to be assigned 
to each of said processors. 

3. Apparatus as claimed in Claim 2 further comprising 
means for providing to each processor any graphical 

is objects that intersect any pixel locations assigned to 
said processor. 

4. Apparatus as claimed in Claim 3 wherein the means 
for scan converting includes each processor includ- 
es ing means for scan converting graphical objects 

received by said processor into pixels. 

5. Apparatus as claimed in Claim 4 wherein the means 
for storing includes means for utilizing user input to 

25 dynamically determine which pixel locations are to 
be assigned to each of said processors. 

6. Apparatus as claimed in Claim 4 wherein the means 
for storing includes means for utilizing optimization 

30 techniques to dynamically determine which pixel 
locations are to be assigned to each of said proces- 
sors. 

7. A method for utilizing multiple processors to render 
35 graphical objects for display comprising the steps of: 

storing in memory a list of pixel locations 
assigned to each of said processors; 

scan converting each received graphical 
object into pixels; and 
^0 each processor rendering graphical object pix- 

els at pixel locations assigned to said processor. 

8. A method as claimed in Claim 7 wherein said step 
of storing includes dynamically determining which 

45 pixel locations are to be assigned to each of said 
processors. 

9. A method as claimed in Claim 8 further comprising 
the step of providing to each processor any graphi- 
cs cai objects that intersect any pixel locations 

assigned to said processor. 

1 0. A method as claimed in Claim 9 wherein the step of 
scan converting includes each processor scan con- 

ss verting graphical objects received by said processor 
into pixels. 

11. A method as claimed in Claim 10 wherein the step 
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of storing includes utilizing user input to dynamically 
determine which pixel locations are to be assigned 
to each of said processors. 

12. A method as claimed in Claim 10 wherein the step $ 
of storing includes utilizing optimization techniques 

to dynamically determine which pixel locations are 
to be assigned to each of said processors. 

13. A data processing system comprising: 10 

a memory for storing data to be processed; 

a processing means for processing data 
stored in memory; and apparatus as claimed in any 
of Claims 1 to 6. 

15 



20 



25 



30 



35 



40 



45 



50 



55 



i 



EP 0 693 737 A2 



o££ g| 

i!ro 
<<S 



CO 



xi-co ^ 
clQ-co 

<<UJ 

coo 
cc 

Q. 







SI 

evil 


LUT 




DAC 



t 




8 



i — r 



VICE 180 




SI 

s 

—1 

o 




21 

CO 


UJ 




cc 




o 


o 








o 

cc 


2 




DO 0/1 




HA 



QC 
UJ 

pi 

CD 
UJ 

< 
CC 









Ol CO 






11 

MAIN " 
CESS0R( 




isi 

s 






PRO 




MAII 



;iu 



2> 
— UJ 

O 



la 



8 



8 



EP 0 693 737 A2 



OPERATING 
SYSTEM 

300 



362 



GRAPHICS 
APPLICATION 
SOFTWARE 

332 



APPLICATION 
PROGRAM 
INTERFACE 
(API) 342 



GRAPHICS 
APPLICATION 
INTERFACE 
(GAI) 352 



DMA 



OPERATING 
SYSTEM 
KERNEL 310 



360 



GRAPHICS 
APPLICATION 
SOFTWARE 

330 



f 



APPLICATION 
PROGRAM 
INTERFACE 
(API) 340 



GRAPHICS 
APPLICATION 
INTERFACE 
(GAI) 350 



DEVICE DRIVER 
(GRAPHICS 
KERNEL) 



370 



" t 



ADAPTER 
MICROCODE 

380 



HOST ^ 
COMPUTER 
MICROCODE 



FIG. 2, 



9 



EP 0 693 737 A2 



PO 


PI 


P2 


PO 


P1 


P2 


PO 


P1 


P2 


PO 


PI 


P2 


PO 


P1 


P2 


PO 



400 



PO 
P1 
P2 



P3 



P4 



P5 



FIG. 3A 



FIG. 3B 



PO 



pi 



P2 



PO 


Pi 










P2 


PO 


P2 


PO 


P1 


P2 


P1 


P2 


PO 


P1 











V 

400 



FIG. 3C 



10 



EP 0 693 737 A2 



10 



Y///////////A 



231 




FIG. 4 



11 



EP 0 693 737 A2 




FIG. 5 



ALLOCATE PROCESSOR 
OWNERSHIP ROUND-ROBIN 
IN UNIFORM BLOCKS 505 



ALLOCATE PROCESSOR 
OWNERSHIP ROUND-ROBIN 
IN UNIFORM STRIPES 515 



GET BUFFER FROM 
USER FOR SPECIFIED 
OWNERSHIP 



525 



1 




RETRIEVE OBJECT 


535| 


— 1 


EXTRACT SUBOBJECT 


540 




COMPUTE SUBOBJECT 
COORDINATES 


545 


I 


COMPUTE & STORE 
SUBOBJECT BOUNDING BOX 


5Joj 



BUILD 
PIXEL/REGION 
OWNERSHIP 
BUFFER 

565 



12 



EP 0 693 737 A2 



CstarQ 
retrieve object 



600 



EXTRACT SUBOBJECT 605 

J 



CALCULATE VARIABLES FOR 
SHADING, TEXTURING, 
LIGHTING, ETC. FOR 

SUBOBJECT 610 



SCAN CONVERT 




SUBOBJECT INTO 




PIXELS 


615 




FIG. 6 



13 



